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ARTICLE INFO ABSTRACT 


Article history: Web applications have experienced a widespread adaptation owing to the agile Service Oriented Ar- 
chitecture (SOA) reflecting the ever-changing software needs of users. Google Meet is one of the top 
video conferencing applications, especially in the post-COVID19 era. Security and privacy concerns are 
therefore critical. This paper presents an extensive digital forensic analysis of Google Meet running on 
multiple browsers and software platforms including Google Chrome, Mozilla Firefox, and Microsoft Edge 
browsers in Windows 10 and Linux. Artifacts, traces of potential evidence, are extracted from different 
locations on a client's desktop, including the memory and browser. These include meeting records, 
communication records, email addresses, profile pictures, history, downloads, bookmarks, cache, cookies, 
etc. We explore how different Random Access Memory (RAM) sizes of client devices impact the 
persistence and format of extracted memory artifacts. A memory artifact extraction tool is developed to 
automate the extraction of artifacts identified via unstructured string analysis. Google Meet forensic 
artifacts are critical in that they are potential digital evidence in relevant criminal investigations. 
Additionally, they highlight that user data can be extracted despite implementing multiple privacy and 
security mechanisms. 
© 2022 The Author(s). Published by Elsevier Ltd on behalf of DFRWS This is an open access article under 
the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). 
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1. Introduction software requirements of users Akremi et al. (2020). This makes it 


harder to implement security controls that work efficiently on 


Video conferencing applications such as Zoom, Microsoft Teams, 
Cisco WebEx, and Google Meet have played a pivotal role in 
achieving the novel work-from-home norm on account of COVID19. 
According to a GetVolIP report, these applications had hundreds of 
millions of active users in 2020 (Stone,). This worldwide prevalence 
has attracted malicious agents’ exploitation of security vulnerabil- 
ities. Attacks include meeting bombing, distributing malicious links 
in chats, stolen meeting links, and host privileges’ transfer (Top 
videoconferencing attacks,). 

Unlike other video conferencing (desktop client) applications, 
Google Meet is essentially a Web application. Web clients pose 
unique challenges for forensic analysts since they depend on agile 
SOA, which enables a dynamic Web infrastructure that deploys 
Web services and applications on a need basis, reflecting changing 
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regular applications. Also, Web applications do not store client 
application folder(s) on disk, which may contain potential forensic 
artifacts. Browser data, “residual data generated on devices, can be 
used as a proxy to data that is being stored in cloud environments,” but 
it provides an incomplete understanding of artifacts pertinent to a 
Web client Cloyd et al. (2018); Case and Richard (2017). Browser 
cache stored on disk does not include meeting and communication 
records, which hold primary forensic relevance as digital evidence 
in investigations. Fortunately, these records can be carved from 
memory, which is fundamental for the extraction of volatile data 
that cannot be found on a disk/network or may exist in encrypted 
form. 

Memory forensics typically focused on detecting rootkits and 
retrieving traces of malware (e.g., resident virus) from a system's 
volatile memory, has seen increasing research and development in 
techniques for extraction and analysis of userland application ar- 
tifacts. Analysis of raw physical memory to extract application data 
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structures optimally requires the application to be open-source 
Schatz and Cohen (2017). Source code analysis makes it possible 
to construct accurate high-level data structures. However, most 
Windows and third-party applications like Zoom, MS Teams, Goo- 
gle Meet, and Cisco WebEx are not open-source. This leads to 
forensic analysts having to reverse engineer structures without 
proprietary code. 

Additionally, the heterogeneity of applications requires this task 
to be performed individually for each application which may lead to 
a loss of time-cost relevance in most investigations. Consequently, 
structured analysis of userland applications may not be possible. 
Finally, string search to identify signatures of application data also 
poses multiple challenges like manual identification of signatures 
from huge memory dumps and incorporating changes in signatures 
with continuous updates of applications (Case and Richard (2017)). 
This is a daunting task to conduct and maintain, but it is a viable last 
resort. Once signatures are identified, operations can be automated 
for efficiency. 

This research aims to perform an extensive memory and 
browser forensic analysis of the (closed-source) Google Meet Web 
client. Three major contributions of this study are presented as 
follows: 


@ An exhaustive (unstructured) memory forensic analysis of 
Google Meet to extract artifacts that contribute to a holistic 
meeting scenario and development of a memory artifact 
extraction tool to automate string signature-based artifact 
carving. 

@ Investigation of the impact of various client device RAM sizes 
on extracted memory artifacts. 

@ Analysis of browser artifacts of Google Meet extracted from 
Chrome, Firefox, and Edge. 


2. Related work 


Memory analysis for Web and desktop client artifacts. Barradas 
et al. (2019) extracted communication records of various Web cli- 
ents and mobile applications (including Facebook, Messenger, 
Skype, Twitter, Outlook, Roundcube, Google Hangouts, WhatsApp, 
Telegram, Trillian, and Gmail) from physical memory using string 
analysis. According to reported results for Web clients, the latter 5 
applications yielded no communication artifacts in Chrome. Simi- 
larly, 7 and 5 applications out of 11 yielded no results in Firefox and 
Edge. The experiments for Web clients were conducted in Virtual 
Machines (VMs) with RAMs of only 1 GB, which is inherently 
inadequate for real-world scenarios. The application data may 
likely be swapped out of memory onto disk (pagefile.sys) when it 
comes to devices with smaller RAMs of 1—4 GB, but this is unad- 
dressed in the experiments and results of the paper. Today, client 
devices have RAMs ranging from 8 to 32 GB, which means they 
have significantly enhanced system load tolerances and application 
string data is bound to persist in memory and/or swap space. To this 
end, we sought to test the hypothesis that RAM sizes may have 
significant effects on the persistence and format of memory artifacts 
which cannot be overlooked while conducting experiments. 

Fernandez-Alvarez and Rodriguez (2022) employed the open- 
source code of the Telegram desktop client to extract artifacts 
prevalent in memory (user account information, communication 
records, contacts, etc.). They recreated the Unified Modeling Lan- 
guage (UML) diagram of Telegram using the source code, which 
helped identify how application objects were stored in memory. 
This gave an exact signature to search for, significantly eliminating 
error and chance of false positives in the extracted artifacts. The 
adopted methodology is an effective approach for investigations 
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involving open-source applications. However, it cannot be applied 
to proprietary software. 

Browser forensics. The client's browser is another source of 
forensic artifacts in cases involving Web clients. Cloyd et al. (2018) 
investigated residual data retained in a browser after a Facebook 
Web browsing session. Public browser modes of Chrome, Firefox, 
and Internet Explorer were reported to retain 46%, 61%, and 52% of 
activities performed in test sessions, respectively. 

Marrington et al. (2012) tested the portable browser mode of 
Chrome (normal and private modes) to investigate whether privacy 
claims regarding portable browsers were legitimate. The authors 
extracted traces of Web browsing activity from the host's disk space 
and warned that users trying to obscure their online activity using 
portable browsers might not be using the most effective method. 

Oh et al. (2011) emphasized that Web browser forensic analyses 
usually comprise log parsing only. The authors suggested that ar- 
tifacts are likely spread out in different locations and an integrated 
analysis is necessary. Possible sources of evidence and different 
kinds of analyses such as timeline analysis, search history analysis, 
user activity analysis, and recovery of deleted information were 
discussed. 

Forensics of video conferencing applications. Forensic analysis of 
video conferencing applications has been an active research topic 
recently. Mahr et al. (2021) performed Zoom's in-depth disk space 
forensic analysis. The authors explored client databases in the 
Zoom data directory to extract artifacts such as contacts, chats, 
email addresses, passwords, cache, and user/device configurations. 
Structured Query Language (SQL) queries used to extract relevant 
data from databases were also tabulated. In addition, preliminary 
memory and network analyses were presented. 

Nicoletti and Bernaschi (2019) presented case studies illus- 
trating the relevance of artifacts extracted from the Voice over 
Internet Protocol (VoIP) codec and protocols of Skype for Business. 
Nicoletti and Bernaschi (2021) also studied Microsoft Teams for 
disk space artifacts. The integration of Teams with Public Switched 
Telephone Network (PSTN) was also explored from a forensics 
perspective. 

Bowling (2021) performed disk space forensic analysis of 
Microsoft Teams in Android, iOS, and Windows, extracting SQLite 
databases and analyzing the caching structure of Teams for 
artifacts. 

Khalid et al. (2021) performed forensic analysis of Cisco WebEx 
in a Windows 10 Operating System (OS), investigating memory, 
disk space, and network artifacts. They extracted user account in- 
formation, communication artifacts, passwords, etc. 

Recent research work by Azhar et al. (2021) detailed forensic 
analysis of Microsoft Teams and Google Meet concerning disk 
space, memory, and network. Their analysis of Google Meet dis- 
cussed Volatility's pslist and netscan outputs of memory dumps and 
History SQLite database on disk, therefore, we report no overlaps 
between our research work. 


3. Google Meet Web client 


Google Meet is an on-the-go video conferencing Web client in 
that the users can conduct quick meetings without downloading a 
desktop application. It offers three meeting scenarios: (1) ‘Create a 
meeting for later,’ (2) ‘Start an instant meeting,’ and (3) ‘Schedule in 
Google Calendar’, as shown in Fig. 1. In addition, users may join 
others' meetings by entering a code/nickname in the application 
User Interface (UI) or joining via an invitation email. No records of 
previous meetings and in-call messages are stored after the 
meeting, according to a note displayed atop the in-call message box 
in Google Meet: ‘Messages can only be seen by people in the call and 
are deleted when the call ends.’ Only records of scheduled meetings 
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New meeting | E Enter a code or nickname 


fe>) Create a meeting for later 
+ Start an instant meeting 


m) Schedule in Google Calendar 


Fig. 1. Meeting options for Google Meet. 


via Google Calendar are kept on the Calendar itself. Other features 
include screen sharing, captioning, and whiteboarding, which uses 
another Google application called Jamboard. 

Google Meet offers attractive features for users with privacy 
concerns since it does not need to be downloaded and no meeting/ 
in-call records are seemingly kept. In our forensic analysis of the 
Web client, we investigate whether communication records and 
other artifacts can still be extracted from memory and browser 
despite the privacy claims. 


4. Experiments 


Test environment. Three Windows 10 VMs with varying memory 
sizes of 4 GB, 8 GB, and 12 GB were created as testbeds to perform 
test activity, simulating the actions of a typical user of Google Meet. 
A Gmail account with its corresponding Google Meet Web client 
was set up in each VM. The test activity was performed on three 
different browsers: Chrome, Firefox, and Edge. Test OSs included 
Windows and Linux. To test on Linux, an additional VM of 8 GB 
RAM was created. 

Test activities. The experiments conducted for forensic analysis 
of Google Meet Web client comprise test user activities which are 
categorized into Test Activity Classes (TAC): 


@ TAC;: includes ‘Create a meeting for later’ and ‘Start an 
instant meeting’. In both scenarios, user activities include 
login, starting the meeting, exchange of 6 (3 sent and 3 
received) in-call messages, screen share, closed captioning 
on, whiteboard activity using Jamboard, and .pdf and .jpg 
downloads of the activity. 

@ TAC2: includes the ‘Schedule in Google Calendar’ scenario. 
User activities include login, scheduling the meeting using 
Google Calendar, starting the meeting, exchange of 6 (3 sent 
and 3 received) in-call messages, screen share, closed 
captioning on, whiteboard activity using Jamboard, and .pdf 
and jpg downloads of the activity. 

@ TAC3: includes joining a meeting set up by another user. User 
activities include login, joining the meeting, exchange of 6 (3 
sent and 3 received) in-call messages, screen share, closed 
captioning on, whiteboard activity using Jamboard, and .pdf 
and jpg downloads of the activity. 


TACs were repeated in all created VMs. The VMs were restarted 
each time to perform successive TACs. Test activities were per- 
formed over a period of two months. Each TAC generated artifacts 
that are categorized into Artifact Classes (AC): 


@ AC; > Traces of Google Meet's usage 
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@ AC > Meeting records 

@ AC3 > Communication records 

@ AC, > Document/image downloads 
@ AC; > Correspondence 

@ ACs > Closed captioning transcripts 


Launching Google Meet in a browser tab creates a process 
named chrome.exe in memory. Memory pages allotted to the tab's 
process are released when the browser/tab is closed. We tested 
differences between extracted artifacts in both scenarios to explore 
artifacts’ persistence: (1) when the meeting had ended but the 
browser/tab was still open and (2) after the browser/tab had been 
closed. These scenarios were tested for each TAC. 

Memory was captured by suspending the VM and duplicating 
the .vmem file using AccessData Forensic Toolkit (FTK) Imager. 
These captures were taken for the two scenarios discussed above 
(for each TAC in every VM), i.e., the browser/tab open vs. closed 
scenarios. 

Browser forensic analysis was performed specifically for Win- 
dows. Forensic images of the disk space were captured by imaging 
the .vmdk file of the VMs. 

Effects of RAM sizes on persistence and format of extracted memory 
artifacts. To test our hypothesis that RAM sizes may have effects on 
extracted application artifacts (discussed in Section “Related 
work”), we conducted the same TACs on Windows VMs of varying 
sizes, i.e., 4 GB, 8 GB, and 12 GB. 

Page smearing. While greater RAM sizes offer better device 
performance, they often lead to page smearing.' In our experiments, 
memory dumps were captured by suspending the VM and dupli- 
cating .vmem file. This prevented smearing from occurring and 
eliminated the issue in our analyses because the memory of the VM 
was frozen and the dump was captured instantly Case and Richard 
(2017). 

In addition, acknowledging that not all investigations involve 
VMs but actual client devices, we performed 5 TAC experiments on 
a laptop host with 12 GB memory to observe the effects of smearing 
on extracted artifacts. We consider at least 1 of the 5 memory 
dumps taken from the host device to be smeared, since smearing 
generally occurs in systems with 8 GB RAM or more (or systems 
under high load) and almost all memory captures contain some 
degree of smear Case and Richard (2017). 

Table 1 lists tools used for forensic analysis of Google Meet. 


5. Memory forensics 


Artifacts extracted via memory forensics contribute to a holistic 
picture of a Google Meet meeting from all TACs. Our analysis 
considered an artifact to be present in memory when it could be 
tied to Google Meet or other Personally Identifiable Information 
(PII) artifacts of the test account for attribution. If an artifact existed 
without any identifier, it was of no use in the investigation. 
Therefore, we considered such artifacts absent. 

Running processes. Running processes (with execution time- 
stamps) related to Google Meet were extracted from memory via 
Volatility and identified as chrome.exe, firefox.exe, and msedge.exe 
for each browser, respectively. Since every tab's process name is 
generic, and not indicative of whether the process belongs to 
Google Meet, a simple yarascan search was done using the ‘google 
meet’ search term to identify the PID of Google Meet's chrome.exe, 
firefox.exe, and msedge.exe processes. Running process results apply 


1 Page smearing is “an inconsistency that occurs in memory captures when the 
acquired page tables reference physical pages whose contents changed during the 
acquisition process” Case and Richard (2017). 
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Table 1 

Tools used for forensic analysis of Google Meet. 
Tool Version 
Windows 10 VM 10 
Linux Debian 10.x 
Google Meet Web client 2021.5.1.1 
AccessData FTK Imager 4.5.0.3 
Volatility 2.6 
PhotoRec 7.2 
Autopsy 4.19.1 
Strings 2.53 
DB Browser for SQLite 3.12.1 
Chromecacheview 2.27 
Chromecookiesview 1.66 
DCode 5.5.21194.40 
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Usage 


Test environment 

Test environment 

Video conferencing Web client to test for forensic artifacts 
Create forensic images of memory and disk 
Memory dump analysis 

Carve jpeg images 

Disk image analysis 

Manual string search 

Browse application databases on disk space 
View Google Meet cache 

View Google Meet cookies 

Timestamp decoding 


memdump.@@1: [[1,nul1,nul1,nul11,nul11,nul1,nul11,nul11,nul1,nul11, [null,null1,3,nul1,"en",2,"boq_meetingsuiserver_20220323.02_p1"]],5, 


[(['1649989113348"},null,[],null,null,null,null,"[[[\"boq_hlaneF22A98EB\", \"MAJKCuZafKyy_xPqRHA\", \"rN@rimAgFm19f-rG-1jbYCII\", 


@c4-5614-45ed-8aa8-a7021a121612 
null,null, 


\"spaces/g3eVBnvBSCcBfdevices/bd74 
null, \"c9641966201854436176_NMS\" 


Device ID g 
Timestamp Meeting name 


\"spaces/g3eV3nvBsCcB\"],null,null,null,null,null, 
[null,null,null,null,null,null,null,null,null,null,null,nulll,null,null,null,null,null,null,null,null,null, ... 


\"bog_hlane_epeédy11Nmc\",null,nul1, \"zainabkhalid2315@gmail.com\" 


Email address 


Fig. 2. Meeting record for TAC). 


B/messages/1649089113096143" , "spaces/g3eV3nvBSCcB/jdevices/bd74f0c4-5614-45ed-8aa8-a7021a121612]' 1649088978481 | [1649089113 , 96143000], 
[['So_ should we start?"]],1],["spaces/g3eV3nvBSCcB/messages/1649089141169967" | "spaces/g3eV3nvBSCcB 


Sent in-call message 


Device ID Timestamp 


Fig. 3. Sent in-call message for 4 GB and 8 GB memory dumps of TAC). 


to all TACs. 

Profile photos and favicon images. Thumbnails of the user account 
avatars, interacted accounts, and other favicon images/logos related 
to Google Meet were carved from the memory dump using Pho- 
torec.” While favicons were a sound trace of usage of Google Meet, 
avatar thumbnails were not useful because they could not be 
associated with Google Meet or other PII. At best, the extracted 
profile avatars may provide a suspect list for the analyst to further 
investigate. The extracted images suggested that Google Meet 
stores profile images in unencrypted form (at least) in the memory 
before communicating them through the network (in contrast to 
the user account password, which was not found in memory in 
plaintext). Profile photos and favicon image results apply to all 
TACs. 

Manual string analysis for extraction of meeting records. We per- 
formed a manual string analysis of the memory dumps using 
strings and grep tools. It is pertinent to note that results exhibited 
homogeneous signatures throughout our test browsers (Chrome, 
Firefox, Edge) and OSs (Windows, Linux). This confirmed that the 
format of high-level string data related to a Web client in memory 
depends on the application itself, independent of the browser/OS 
used, as reported by Barradas et al. (2019). Extracted manual arti- 
facts presented in the following apply to all test browsers and OSs. 
Note that information related to an artifact (metadata) is repre- 
sented in the roster notation of sets in this paper for a compre- 
hensive yet compact presentation. 

TAC). The string signatures of artifacts pertaining to ‘Create a 
meeting for later’ and ‘Start an instant meeting’ scenarios were 


2 https://www.cgsecurity.org/wiki/PhotoRec. 


similar; therefore, they are represented by TAC). A trace of usage 
found for these scenarios in memory was Google Meet link file(s): 
google meet.Ink. 

AC, > Trace of Google Meet's usage = {.Ink file(s)} 

Meeting records for TAC; were extracted with meeting names, 
email address of the test user, device ID, and timestamp of the 
meeting, as shown in Fig. 2. The email address and device ID serve 
as the PII of the test user. 

AC2 > Meeting records = {meeting name, email address, device 
ID, timestamp} 

From 4 GB to 8 GB memory dumps of TAC), sent messages were 
recovered (extracted information included the in-call message, 
device ID, and timestamp), as shown in Fig. 3 However, received 
messages were not found in memory for these RAM sizes. 

For 12 GB memory dumps of TAC), sent messages were recov- 
ered in a format different than that of 4 GB and 8 GB dumps. All 
messages sent by the test user were found collectively, in a single 
page line in memory along with the associated metadata (Fig. 4). 
This was in contrast to 4 GB and 8 GB dumps, where each of the sent 
in-call messages existed separately (with their metadata). In 
addition, received messages were also recovered in the 12 GB 
dumps, as shown in Fig. 5. 

This difference in persistence and format of artifacts extracted 
from 4 GB, 8 GB, and 12 GB memory dumps confirmed our hy- 
pothesis that the amount of RAM available largely affects the arti- 
facts extracted. Therefore, researchers and analysts must be wary of 
this in investigations. 

AC3 > Communication records = {sent/received in-call message, 
device ID, timestamp} 

Document/image downloads via whiteboarding were identified 
for TAC; with the document/image name, the type of file (i.e., .pdf or 
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1649238041138, [1649238237 ,426783000], 


Timestamp 


(‘what are we to discuss, today" 
“spaces/tVzo_9T30xIB/devices/8883883c-37f5-4ad7-bc9d-66e8bafelff4" , 1649238041139, [ 1649238260, 937183000], ||" sweet lets do it" ]},1]]]]] 


2nd sent in-call message 
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FEEFEE : 4 


GT30xIB/méssages/ 1649238260: 


],1],["spaces/tvzo | 937183", 


1st sent in-call message 
3rd sent in-call message 


Device ID 


Fig. 4. Sent in-call message for 12 GB memory dump of TAC}. 


BSCcBjdevices/3e5727d6-419d-49a5-9a87 -54db54325ad4"|, 2361596192 , []1649989125} 330879000], [f'Yes absolutely']],1],["spaces/g3eV3nvBSCc... 


Device ID 


Timestamp 


Received in-call message 


Fig. 5. Received in-call message for 12 GB memory dump of TAC). 


png), size of the file, email address of the test user, Jamboard link 
used to perform the whiteboard activity, and directory path of the 
stored file. 

AC, > Document/image downloads = {document name, type, 
size, email address, directory path, Jamboard link} 

The email addresses of other accounts the test user interacted 
with were extracted in a format that proved that the corresponding 
account was part of a Google Meet meeting. However, it could not 
be tied to a specific meeting. 

ACs > Correspondence = {email address} 

Closed captioning transcripts were found in memory but 
without any specific string signature/format. 

ACs > Closed captioning transcripts = {} 

TAC. Artifacts extracted for TAC} were majorly similar to TAC, 
as expected. However, the difference existed in ACo, i.e., the 
extracted meeting records where the meeting title of the scheduled 
meeting, as set in Google Calendar, was also extracted. 

AC > Meeting records = {meeting title set in Google Calendar, 
meeting name, email address, device ID, timestamp} 

In addition, received in-call communication records for 12 GB 
memory dumps of TAC, were also extracted in a collective/chained 
format as discussed for sent in-call messages of 12 GB dumps of 
TAC}. 

TAC3. The artifacts extracted for TAC3 (test user joining a meeting 
set-up by another user) were less detailed in the case of certain ACs, 
i.e., AC3 and ACy, compared to previous TACs. The remaining ACs of 
TAC3 were similar to TAC; and TAC. 

Communication records extracted for all RAM sizes were in the 
format:  1,1651046186694,null,["<message>"],1]]. This only 
divulged the sent/received in-call message along with the time- 
stamp. Sent in-call messages were also recovered in the form of 
<div> HTML tag clippings: up today">what is up today</ 
div> </div> </div>. However, lack of signatures for extraction 
rendered this format useless. 

AC3 > Communication records = {sent/received in-call message, 
timestamp} 

Information extracted related to AC, (document/image down- 
loads) was also comparatively limited, as shown below. 

AC4 > Document/image downloads = {document name, type, 
directory path, Jamboard link} 

Browser/tab open vs. closed. For memory dumps captured for all 
TACs, we observed whether extractable artifacts persisted in 
memory after the browser had been closed. Our analyses revealed 
that all ACs were extractable with no difference except AC3 
(communication records) and ACs (correspondence). Some sent 
and received in-call messages were absent and the interacted ac- 
count's email address was absent after the browser was closed. 
These results apply to all TACs. 


AC, 
closed 
captioning 
transcripts 


sent/received in- 
call messages 


AC, 


message 
timestamp 


meeting name 


AC; 


correspondence 
email(s) 


meeting title 
(scheduled case) 


C, 


meeting 
timestamp 


doc name 


doc type 


AC, 


doc size 


Jamboard 


doc path link 


Fig. 6. Google Meet forensic artifacts. 


Fig. 6 illustrates a holistic diagram of all forensic artifacts 
pertinent to a Google Meet meeting. The diagram represents all 
TACs in a general manner. While AC, provides a trace of usage for 
Google Meet, ACs and ACs cannot be tied to a meeting (directly) via 
PII in any case. 

Page smearing. Artifacts extracted from memory dumps of the 
laptop host exhibited similar results as observed in .vmem memory 
dumps discussed in the previous section. Page smearing did not 
majorly affect the extraction of memory artifacts in this case. This 
was expected because manual analyses of string-based userland 
applications’ artifacts are based on a signature-matching algorithm, 
extracting artifacts if matched with a pre-defined signature. Once 
signatures are identified in the research phase, the related artifacts 
can generally be extracted from wherever they exist in the memory 
even when the process memory allocated to the subject process is 
smeared. 

If page smearing causes inconsistencies mid-page line, artifacts 
may be extracted in clipped form. But this assumption was not 
identified in any of the 5 memory dumps acquired from the laptop 
host as the artifacts extracted were complete and consistent with 
the ones extracted from .vmem memory dumps. 

Memory artifact extraction tool. Our python-based proof of 
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"> 587, 
"KeyState.Live", 
“meet_store", 


[\"bog_hlane_I92507BX684\", 


"key": “clientRegistrations" 


"key": "b'\\x@0\\x02\\x@1\\xO1\\x@1\\x13\\x8@c\\xOO1\\xO@i\\xeGe\\x8On\\xEt \ \x@OR\ \xO@e\\xO0g\\xO0i\\xOAs\\xOOt\\xOOr\\xeGa\\xOOt\\xO0i\\x@G@0\\x80n\\xOes'", 
“origin file": "C:\\Users\\HP\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\IndexedDB\\https_meet.google.com_@.indexeddb. leveldb\\000003.log", 


\"spaces/dnZOx4ufg04B/devices/e87e30bc -0076-4e42-93d4-dff5186880b7\", 
null, \[tie-umyp-nio\"|, "Test Meeting #1\"|,false,true,false]]]]", 
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Fig. 7. Meet_store object with scheduled meeting link and title extracted via Google Meet IndexedDB-LevelDB. 


concept memory artifact extraction tool? automates the extraction 
of manual string artifacts pertaining to Google Meet, employing the 
signatures identified in memory forensic analysis. 


6. Browser forensics 


Disk images captured after test user activity with Google Meet 
were analyzed using Autopsy to extract forensic artifacts. Our target 
artifacts in browser forensics included traces of the application's 
usage, history, downloads, bookmarks, cache, cookies, and relevant 
Uniform Resource Locators (URLs). Other artifacts such as associ- 
ated profile pictures, email addresses, meeting links, and in-call 
messages were also extracted and documented from the disk 
image. 

Traces of usage. Traces of Google Meet's usage from the browser 
were detected using several artifacts. In the Web Applications folder 
(AppData\Local\ Google\ Chrome\ User Data\ Default\ Web 
Applications\|.*]), a folder containing the Google Meet icon and its 
md5 hash was extracted. No other information was stored in the 
folder; however, it is an indicator of the Web application's usage on 
the client device. Subjectively, Google Meet was found in the icons of 
the recently closed sites folder (AppData\ Local\Google\Chrome\ User 
Data\ Default\ JumpListIconsRecentClosed) and in the most visited sites 
folder (AppData\Local\ Google\ Ch-rome\ User Data\ Default\ 
JumpListIconsMostVisited) depending on the frequency of usage. 
SQLite database Top Sites in AppData\Local\Google\Chrome\ User 
Data\ Default also listed Google Meet as one of the top sites the user 
engaged with; also subjective. 

IndexedDB-levelDB folder. The IndexedDB folder at AppDa- 
ta\Local\Google\Chrome\ User Data\Default\IndexedDB stores lev- 
elDBs of Web applications used by the user. LevelDB is a novel key- 
value structured database which stores session data related to a 
Web application (Caithness,). Once Google Meet was used, a folder, 
https_meet.google.com0_.indexeddb.leveldb, was created in the 
IndexedDB directory. This is a solid trace of usage, unlike prior in- 
dicators. After converting the IndexedDB-levelDB into a readable 
format (.json*), an analysis of the structure's storage format 
revealed that in the Google Meet levelDB, two object stores, namely 
IndexedStorage and meet_store were classified. IndexedStorage 
was found to be of no forensic relevance since it mainly logged 
.woff2 font packages for the application. On the other hand, the 
meet_store revealed meeting IDs of all the previously held and 
joined meetings by the user, along with the GUID of the user. In case 
the meeting was a scheduled meeting via Google Calendar, the 
meeting title was consequently stored in the database as well, as 
shown in Fig. 7. It is pertinent to note that the object store did not 
store timestamps along with meeting IDs therefore the extent of 
forensically relevant clues the Google Meet levelDB may divulge is 
‘whether a suspect used Google Meet or not?’ and ‘was (s)he part of 


3 https://github.com/farkhund/googlemeet. 
4 https://github.com/Ixndrblz/forensicsim. 


a certain meeting or not?“. 

PII. The email address associated with the Google Meet account 
was extracted from the Login Data and Web Data SQLite databases. 
The avatar associated with Google Meet was extracted from App- 
Data\Local\ Google\Chrome\ User Data\ Default\Accounts\Avatar 
Images. Note that this is essentially the profile picture of the Google/ 
Gmail account associated with Google Meet. If more than one av- 
atars exist, it indicates usage of more than one Google account in 
which case attribution becomes trickier. This problem can be solved 
using cache entries of avatars discussed later. 

Communication records. In Google Meet, an attractive feature is 
that the history of meetings and exchanged in-call messages is not 
recorded anywhere on the Web application (apart from meetings 
that are scheduled using Google Calendar, in which case it is possible 
to track down the history (meeting names) of scheduled meetings 
via Google Calendar). However, we identified logs in the Google 
Chrome data directory that stored information related to meetings 
conducted, including in-call messages exchanged. The Sessions 
folder (AppData\Local\Google\Chrome\User Data\Default\ Sessions) 
stored logs of Web applications, tabs, and sessions. From the [App_#] 
logs, the Google Meet meeting links and in-call messages (following 
the <chatTextInput > and < textarea > tags) were extracted. The in- 
call messages extracted were scattered and fragmented, rendering 
the extraction a highly manual task, but in cases where messages 
play a pivotal role and capturing memory is not possible, parsing the 
logs is an option. 

Browser artifacts. Google Meet bookmark saved in the Chrome 
browser was extracted from (AppData\Local\Google\Chrome\ User 
Data\ Default\Bookmarks) with a timestamp, ID, and name of the 
bookmark. 

The history of Google Meet meetings extracted from the History 
SQLite database stored in AppData\Local\Google\Chrome\ User 
Data\ Default\ History contained not only the browsing history (with 
timestamps, visit counts, and durations of visits) but also the 
keyword search terms entered in the browser and downloads (with 
names of files downloaded, sizes, start and end times of download, 
referrer URLs from which they were downloaded, and paths to 
folders they were saved in). Details regarding downloaded files 
were also found in the Download Metadata file in AppDa- 
ta\Local\ Google\ Chrome\ User Data\Default\Download Metadata. 

In case a suspect deletes the browsing history directly from the 
browser, it effectively clears all tables in the History database 
except for the downloads, downloads_url_chains and url tables. 

The cookies related to Google Meet were extracted from App- 
Data\Local\ Google\ Chrome\ User Data\ Default\ Network\ Cookies and 
AppData\Local\Google\Chrome\User Data\Default\Safe Browsing 
Network\Safe Browsing Cookies with names, host keys, values, crea- 
tion times, expiration times, and last accessed times. 

The cache folder (AppData\Local\Google\Chrome\User Data- 
\Default\Cache) stored multiple Google Meet artifacts of forensic 
relevance. Profile pictures of the user and accounts the user inter- 
acted with were found in formats: [.*]-[.*]-[.*]jfif, photo.jpg.jfif, and 
.png. The extracted profile pictures were associated with the 
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Table 2 


Directory paths for pertinent Google Chrome browser artifacts. 
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\Network\ Cookies, AppData\Local\Google\Chrome\User Data\Default\Safe Browsing 
\IndexedDB\https_meet.google.com_0.indexeddb.leveldb 


\Download Metadata 
\Accounts\ Avatar Images 


\Web Applications\|[.*], AppData\Local\Google\Chrome\User 


Data\Default\JumpListIlconsRecentClosed, AppData\Local\Google\Chrome\User Data\Default\JumpListlconsMostVisited, 


Artifacts Directory paths 
History AppData\Local\Google\Chrome\User Data\Default\History 
Bookmarks AppData\Local\Google\Chrome\User Data\Default\ Bookmarks 
Cache AppData\Local\Google\Chrome\User Data\Default\ Cache 
Cookies AppData\Local\Google\Chrome\User Data\Defaul 
Network\Safe Browsing Cookies 
IndexedDB- AppData\Local\Google\Chrome\User Data\Defaul 
levelDB 
Downloads AppData\Local\Google\Chrome\User Data\Defaul 
Profile picture © AppData\Local\Google\Chrome\User Data\Defaul 
Email address = AppData\Local\Google\Chrome\User Data\Default\Login Data 
Browsing AppData\Local\Google\Chrome\User Data\Default\Sessions 
sessions 
Traces of usage AppData\Local\Google\Chrome\User Data\Defaul 
AppData\Local\Google\Chrome\User Data\Default\Top Sites 


Table 3 


Directory paths for pertinent Mozilla Firefox browser artifacts. 


AppData\Roaming\ Mozilla\ Firefox \Profiles\[#].default-release\ places, AppData\Roaming\Mozilla\ Firefox \ Profiles \|[#].default-release\ formhistory 


AppData\Local\Mozilla\ Firefox \Profiles\[#].default-release\cache2, AppData\Local\Mozilla\ Firefox \ Profiles \[#].default-release\ jumpListCache 


AppData\ Roaming\ Mozilla\ Firefox \ Profiles \[#].default-release\favicons, AppData\ Roaming \Mozilla\ Firefox \ Profiles \|#].default- 
release\storage\default, AppData\ Roaming \ Mozilla\Firefox\ Profiles\ [#].default-release\AlternateServices, AppData\Roaming\Mozilla\Firefox\Profiles\ 


[#].default-release\enumerate_devices, AppData\Roaming\Mozilla\Firefox\ Profiles\[#].default-release\ SiteSecurityServiceState 


Artifacts Directory paths 
History 
Bookmarks AppData\Roaming\Mozilla\Firefox\ Profiles\[#].default-release\ places 
Cache 
Cookies AppData\ Roaming \ Mozilla\ Firefox \ Profiles \[#].default-release\ cookies 
Downloads AppData\Roaming\Mozilla\Firefox\ Profiles\[#].default-release\ storage \default\https+++jamboard.google.com 
Profile AppData\Local\Mozilla\ Firefox \Profiles\[#].default-release\ jumpListCache 
picture 
Traces of 
usage 
Table 4 


Directory paths for pertinent Microsoft Edge browser artifacts. 


t\Cookies, AppData\Local\Microsoft\Edge\User Data\Default\Safe Browsing Cookies 
t\IndexedDB\https_meet.google.com_0.indexeddb.leveldb, AppData\Local\Microsoft\Edge\User 


Artifacts Directory paths 
History AppData\Local\Microsoft\Edge\User Data\Default\ History 
Bookmarks AppData\Local\Microsoft\Edge\User Data\Default\ Bookmarks 
Cache AppData\Local\Microsoft\Edge\User Data\ Default\Cache\Cache_Data 
Cookies AppData\Local\Microsoft\Edge\User Data\Defau 
IndexedDB- AppData\Local\Microsoft\Edge\User Data\Defau 

levelDB Data\Default\Local Storage\leveldb 
Downloads AppData\Local\Microsoft\Edge\ User Data\Default\ History 
Profile picture = AppData\Local\Microsoft\Edge\User Data\Default\Cache\Cache_Data 
Email address AppData\Local\Microsoft\Edge\User Data\Default\Web Data 
Browsing AppData\Local\Microsoft\Edge\User Data\ Default\Sessions 

sessions 
Traces of usage AppData\Local\Microsoft\Edge\User Data\Defau 


t\JumpListIconsRecentClosed, AppData\Local\Microsoft\Edge\User Data\Default\Service 


Worker\ Database, AppData\Local\ Microsoft\Edge\ User Data\Default\Favicons, AppData\Local\Microsoft\Edge\ User Data\Default\Network Action 
Predictor, AppData\Local\Microsoft\Edge\User Data\Default\Shortcuts, AppData\Local\Microsoft\Edge\ User Data\Default\Top Sites 


corresponding Google Meet URLs making them an effective attri- 
bution artifact. Other icons in the cache included Google Meet logos. 
‘join call’ and ‘leave call’ audio tunes were cached. Other links per- 
taining to Jamboard sessions and Google Calendar were also found in 
the cache, given either application was used in correspondence to 
Google Meet. A meeting scheduled via Google Calendar specifically 
stored all the information in the cache regarding the meeting like 
meeting/conference ID, name and description of the meeting, loca- 
tion, creator and attendees’ email addresses, start and end time- 
stamps of meeting, time zones, call UID, and HTML link. The cache 
also included application UIs with operator parameters, meeting 
settings, and searches made using the browser. Some interesting 


cache entries found were various location predictions of the user 
during meetings that were conducted using maps by Google. The 
server IP addresses, server names, last accessed timestamps, and 
expiration timestamps of cached entries were also recovered. Note 
that if a suspect manually deletes the cache from the data directory, 
it effectively deletes all Google Meet cache artifacts. 

Similar browser forensic analyses of Firefox and Edge were 
performed. In the case of Firefox, the major source of artifacts was 
the places SQLite database, which revealed the history (and met- 
adata) of meetings conducted using Google Meet. It is pertinent to 
note that Chrome and Edge are built on Chromium's same under- 
lying technology. On the other hand, Firefox operates on the 


F Iqbal, Z. Khalid, A. Marrington et al. 


Quantum engine built specifically for the browser. This results in 
Chrome and Edge having similar data directory structures. 

Tables 2—4 detail the directory paths of every artifact found in 
each browser's data directories. Evidently, Firefox does not have 
some evidence sources such as an IndexedDB-levelDB folder owing 
to its different browser engine and data directory structure. 


7. Case study 


A forensic analyst investigating a case of an insider attack tar- 
geting confidential company data was able to acquire memory and 
disk images of a suspect employee, Eve's laptop PC. In order to prove 
Eve's communication link with Bob, who was identified earlier to be 
in contact with the insider, forensic images from Eve's device were 
analyzed. 

Google Meet, as one of the running applications on the device, 
was further explored in the Chrome data directory. A record of Eve's 
meetings (with IDs) conducted via Google Meet was recovered 
from the application's levelDB. The meeting IDs were further 
explored in the memory dumps. Timestamps of the meetings along 
with sent and received in-call messages (also with timestamps) 
were carved. Emails of accounts in correspondence with Eve were 
also recovered. These artifacts correspond to AC, AC3, and ACs: 

AC > Meeting records = {meeting name, email address, device 
ID, timestamp} 

AC3 > Communication records = {sent/received in-call message, 
device ID, timestamp} 

ACs > Correspondence = {email address} 

While Bob's email address was extracted in ACs (which proved 
Eve was in contact with Bob through Google Meet), the specific in- 
call messages received by Eve were only identifiable via the device 
ID as PII. In order to prove the received messages were sent by Bob, 
his email address (from ACs) and the device ID (from AC3) needed 
to be linked. Fortunately, this information was cross-checked from 
memory dumps taken from Bob's device (ACz from Bob's device 
tied both his email address and device ID together). 


8. Conclusion and future work 


Web applications are an efficient solution to the dynamic soft- 
ware needs of today's users. However, this dynamic nature presents 
challenges in the implementation of security controls, thereby 
increasing the attack surface. Our research aimed to perform a 
detailed forensic analysis of Google Meet to extract memory and 
browser artifacts that may serve as evidence in a court of Law. 

We conducted an in-depth memory forensic analysis of Google 
Meet employing manual string analysis to extract traces of usage, 
detailed meeting records, communication records, information 
related to whiteboard activity downloads, and correspondence 
emails. We also explored the effects of various client device RAM 
sizes and page smearing on the extracted memory artifacts. In 
addition, we developed a memory artifact extraction tool to auto- 
mate the extraction of the string signature-based artifacts. 

This study also presented an exhaustive browser forensic anal- 
ysis of Google Meet on Google Chrome, Mozilla Firefox, and 
Microsoft Edge extracting traces of usage, history, downloads, 
bookmarks, cache, cookies, profile picture, email addresses, 
meeting information, and in-call message logs related to the Web 
application. 

This work can be further extended in multiple directions. Other 
OSs such as macOS, Android, and iOS may be tested for Google Meet 
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forensic artifacts. Other Web clients and video conferencing ap- 
plications can be put to the test of forensic analysis to investigate 
information they give away, being a pivotal element as evidence in 
criminal investigations. 
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